In enterprises which design and implement computer software, testing that software can be a tortuous process. As software applications increase in size and complexity, an enterprise may automate the process of software testing, ensuring that incremental software builds work the way they are intended. Using a computer to test software presents a challenge in determining whether application output was properly generated. In the case of applications which work with documents as data, testing application output may involve verifying that the layout of an outputted document is proper.
Existing solutions for verifying the layout of a document created by a software application may include using methods which are inefficient and which may lead to unwanted false negative and/or false positive test results. These methods may include having a person view a document in comparison to a model or master document. Other methods may involve a software module analyzing a test document against a master document, perhaps by performing a pixel-by-pixel analysis. Other methods may involve the comparison of properties of components (e.g., graphics, text, etc) on a test document to the properties of objects on a master document.
FIGS. 2A-2C depict some of the known methods for verifying the layout of test document 202 by comparing it to the layout of model document 201. FIG. 2A depicts the two documents, which may have been electronically rendered (e.g., on a computer screen), electronically stored (e.g., in a data file), transferred to another medium (e.g., printed on paper), and so forth. FIG. 2B depicts the two documents 201 and 202 being inspected on a pixel-by-pixel basis, as shown under magnified views 211 and 212. As can be seen, the two documents, which look to be the same, actually have different pixels with different shades/colors. This may be due to an actual layout error caused by a formatting software application. In addition, this pixel difference may be the result of differences in resolution of the final output (e.g., screen pixel count or printer dots-per-inch (DPI)). Also, such differences may be the result of computer smoothing algorithms such as anti-aliasing. Regardless of source, this pixel difference may result in a negative verification result, even though test document 202 may be adequately similar in layout to model document 201. This result may be considered a false negative. The number of false negative test results can be quite high using a pixel-by-pixel analysis, making such a test ineffective except for the case when pixels are identical.
FIG. 2C provides collections of property values 221 and 222 for components as they are laid out respectively on documents 201 and 202. Here, property values 221 and 222 represent partial descriptions of a circle and an oval (e.g., position, size, color, and so forth) on each of the documents. These components are found on both model document 201 and test document 202. The layout of test document 202 may be verified by comparing the test values 222 to the master values 221. If the values are the same, then a test application presumes that the documents are laid out the same. This presumption may be invalid, as the actual rendering of the document may vary between computers and/or builds of the software application being tested. Moreover, slight numeric variations, as noted in circle center position 225, might lead to false negative results if the final rendition does not vary in a meaningful way.
It is with respect to these and other considerations that the present invention has been made.